Appln.No. 10/081,502 

Amendment dated May 29, 2007 

Reply to Office Action of February 27, 2007 

Docket No. BOC9-2001-0017 (261) 

REMARKS/ARGUMENTS 

These remarks are made in response to the Office Action of February 27, 2007 
(hereinafter Office Action). As this response is timely filed within the 3-month shortened 
statutory period, no fee is believed due. The Office, however, is expressly authorized to 
charge any deficiencies or credit any overpayments to Deposit Account 50-0951. 

Claims 1, 3, 6-12, and 15-18 were rejected under 35 U.S.C. 102(e) as being 
anticipated by U.S. Patent No. 6,421,672 to McAlister, et al. (hereinafter McAllister). 
Claims 4-5 and 13-14 were rejected under 35 U.S.C. 103 (a) as being unpatentable over 
McAllister in view of U.S. Patent No. 6,256,630 to Gilai, et al. (hereinafter Gilai). 

Applicants have cancelled claims 1-18 and added claims 19-38 to more clearly 
define the present invention and to further emphasize differences between the present 
invention and the cited prior art references. As discussed herein, the claim amendments 
are fully supported throughout the Specification. No new matter has been introduced by 
the claim amendments. 

Applicants ' Invention 

It may be useful to reiterate certain aspects of Applicants' invention prior to 
addressing the cited references. One embodiment of the invention, typified by newly- 
presented Claim 19, is a method of disambiguating database search results. The method 
can include retrieving multiple database entries responsive to a database search, the 
database entries including a plurality of common data fields (such as "Name," "Former 
Name," and/or "Phone," as shown in Fig. 1). The method also can include processing 
data items in each of the data fields of the retrieved database entries according to 
predetermined disambiguation criteria (such as "Failed Duplicate," "Failed Cannot 
Pronounce," and/or "Failed Items Too Long," as shown in Fig. 1). The method further 
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can include, based upon the processing, identifying from among the plurality of common 
data fields at least one disambiguation data field (such as the data fields "Location" and 
"Job Description," as shown in Fig. 1) which satisfies the predetermined disambiguation 
criteria. 

The method further can include selecting one disambiguation data field based on a 
predetermined selection criterion (such as "smallest average length," as described at page 
7, lines 10-12, of the Specification) when more than one disambiguation data field (such 
as data fields "Location" and "Job Description") is identified in the identifying step. The 
method additionally can include presenting, through a speech interface, data items 
corresponding to the selected disambiguation data field for each retrieved database entry, 
the speech interface being used in conjunction with a system in which the database search 
is performed. Moreover, the speech interface can provide an interface for searching 
information contained within a database and for audibly receiving results of the database 
search. 

Another embodiment of the invention, typified by Claim 24, is a method of 
disambiguating database search results. The method can include retrieving multiple 
database entries responsive to a database search, the database entries including a plurality 
of common data fields (such as "Name," "Former Name," and/or "Phone," as illustrated 
in Fig. 1). The method also can include processing data items in each of the data fields of 
the retrieved database entries according to predetermined disambiguation criteria (such as 
"Failed Duplicate," "Failed Cannot Pronounce," and/or "Failed Items Too Long," as also 
shown in Fig. 1). 

Additionally, the method can include, based upon the processing, identifying from 
among the plurality of common data fields at least one disambiguation data field (such as 
the data fields "Location" and/or "Job Description," as shown in Fig. 1) which satisfies 
the predetermined disambiguation criteria. The method further can include selecting one 
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disambiguation data field based on a user input (as described at page 8, line 23, to page 9, 
line 1, of the Specification) when more than one disambiguation data fields (data fields 
"Location" and "Job Description") are identified in the identifying step. The method 
additionally can include presenting, through a speech interface, data items corresponding 
to the selected disambiguation data field for each the retrieved database entry, wherein 
the speech interface is used in conjunction with a system in which the database search is 
performed. Moreover, the speech interface can provide users of the system with an 
interface for searching for information contained within a database in which the database 
search was conducted and with an interface for audibly receiving results of the database 
search. 

The Claims Define Over The Prior Art 

McAllister is directed to a system and method for electronically searching a 
telephone directory utilizing secondary information contained in subscriber listings to 
disambiguate search results (See, e.g., Abstract). Although, like the present invention, 
McAllister also concerns disambiguation of search results, the concept of McAllister is 
totally different from the concept of the present invention. 

In McAllister, when multiple listings satisfying a primary or initial search request 
are found, a series prompts are used to solicit further information relative to the 
ambiguous results (see column 2, lines 45-46). The prompts are composed based on 
distinguishing information (such as a disambiguation data field) identified by the system 
using a hierarchical search pattern (see column 3, lines 34-37). However, McAllister 
does not concern the selection of the best disambiguation data field when multiple 
disambiguation data fields are identified. 

It follows, accordingly, that McAllister does not expressly or inherently teach 
selecting one disambiguation data field based on a predetermined selection criterion or 
based on a user input when more than one disambiguation data fields are identified in the 
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identifying step, as recited in independent claims 19, 24, 29, and 34 of the instant 
application. Also, in identifying the disambiguation data fields, McAllister does not 
consider whether the pronounceability (see claims 21, 26, 31, and 36 of the instant 
application) or length (see claims 22, 27, 32, and 37 of the instant application) of the data 
items. 

Col. 3, lines 34-54 of McAllister, cited in the Office Action, 

"Upon identifying the parties listed in the table above as candidates s the system 
uses a hierarchical search pattern to identify distinguishing information about the 
parties for presentation to the caller. As previously mentioned, conventional 
systems typically provide the caller with the names and telephone numbers of all 
of the candidate entries. Instead, the present system may first look to the 
Department field of the candidate entries to determine if they are unique. In this 
example, two of the candidate parties work in engineering, so that this category of 
information may not be useful to help select the correct party to be called. The 
system may next look to the location field and, as in the example above, determine 
that this information is unique among the candidates. The system would then 
provide the caller with both the name and location of the identified listings and 
ask the caller to select among the parties, typically by saying or using a keypad to 
input the number of the selection, e.g., "Say or push 7 * to dial Robert Cook in 
Arlington, Virginia; 7' for the Robert Cook in Philadelphia, Pennsylvania; and 
\3 for Mr. Cook in Silver Spring, Maryland. " 

The procedure described in the above paragraph may be considered as part of the 

processing step in order to identify disambiguation data fields (containing unique data 
items among the retrieved database entries), but it does not describe how to select the best 
disambiguation data field when there are multiple disambiguation data fields. 

Similar to McAllister, the present invention also teaches the identification of a 
secondary field that can be used for disambiguation. McAllister, however, stops the 
search as soon as the first field is identified. The present invention, in contrast to 
McAllister, continues analyzing all of the fields that meet the criteria to determine which 
field will work the best for users who must remember and repeat the information in the 
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field after hearing a dynamically-constructed prompt based on the best field for a speech 
user interface that has users repeat what they have heard. 

McAllister includes in the database record pronunciation rules or audio files that 
ensure the correct pronunciation of the person names in the database (the primary key), 
but this is different than what the present invention teaches. The present invention 
teaches the use of analysis rules (predetermined speech interface criteria) that are in the 
program, not the database, and that examine the secondary data and use pronouncability 
as a criterion for selection of the best secondary field to use for disambiguation. The 
data from the secondary field are then used to construct a dynamic grammar to enable 
along with the audio presentation of the choices. 

Thus, the use of audio files in McAllister actually teaches away from the present 
invention. In direct contrast to McAllister, the present invention dynamically assesses the 
best secondary field to use for disambiguation and, as part of that process, assesses which 
field is the most pronounceable - not only for the quality of presentation to the caller, but 
also for ensuring that the caller will be able to remember and repeat the presented speech 
option. To reiterate, the present invention is concerned not only with correctly 
pronouncing the secondary data in the automatically generated prompt, but also with the 
ease of pronounceability of the data item by the user. This feature is not addressed by 
McAllister due to McAllister reliance on a "say or push 1" user interface style. 

Although Gilai mentions the word "ambiguous" in the title of the patent, 
Applicants respectfully submit that Gilai has no relevant relationship to the present 
invention. With regard to the rejections to previous claims 3, 7, 12, 16, the references do 
not teach the features recited. Specifically, the references do not teach that, in a speech 
system, an "exception pronunciation" is a pronunciation that is incorrect if produced 
according to the standard rules of a text-to-speech (TTS) engine and thus requires an 
exception pronunciation. Rather, the most common way to handle such a condition is to 
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make an entry in the exception dictionary that the TTS engine references before applying 
its standard rules. Thus, rather than "not being able to be accurately pronounced," 
McAlllister describes a standard way of ensuring that the data can be pronounced by a 
TTS engine. Applicants respectfully point out that building up this list of exceptions can 
be very time-consuming, and is a step that the present invention does not require. 

In the cited portion (column 4, lines 23-25), McAllister does not describe a 
process that excludes data fields having data items that are not able to be pronounced 
using the speech interface. Rather, McAllister describes a process that has nothing in 
common with the present invention. McAllister describes the use of a phonemic spelling 
of names (the primary key) to help to determine whether or not to include a name in the 
initial listing of results. With the present invention, the exclusion of non-pronounceable 
or difficult-to-pronounce data is applied to the secondary fields after eliminating 
potentially ambiguous secondary fields. In McAllister, by contrast, if the system hears 
"Cook," then it cannot exclude the possibility that the name is spelled "Koch." If, 
however, the system hears "Koch" (pronounced as "K AA CH"), then it can exclude the 
possibility that the name is spelled "Cook." Again, this has nothing to do with the present 
invention. McAllister eliminates elements from the primary data field, whereas the 
present invention selects the best secondary data field to use for disambiguation based on 
an assessment of the pronounceability of its data items. 

Accordingly, Applicants respectfully submit that all the claims of the instant 
application define over the cited prior art and request the rejections under 35 USC 102 
and 35 USC 103 be withdrawn. 

CONCLUSION 

Applicants believe that this application is now in full condition for allowance, 
which action is respectfully requested. Applicants request that the Examiner call the 
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undersigned if clarification is needed on any matter within this Amendment, or if the 
Examiner believes a telephone interview would expedite the prosecution of the subject 
application to completion. 



Respectfully submitted, 



Date: May 29, 2007 




Gregory A. Nelson, Registration No. 30,577 
Richard A. Hinson, Registration No. 47652 
Yonghong Chen, Registration No. 56,150 
AKERMAN SENTERFITT 
Customer No. 40987 
Post Office Box 3188 
West Palm Beach, FL 33402-3188 
Telephone: (561)653-5000 
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